Proposing Mobile Pair Programming

1 Background Learning in small groups is deemed highly effective. Given this observation, pair programming appears to be a natural setting for learning how to program. However, even in groups learning takes considerable time and pair programming has some prerequisites that are not easily met, not even in a university setting: it requires suitable facilities where students can work on a computer sitting side-by-side, discussing aloud without disturbing others, and it requires sufficiently long time slots during which students actually have the opportunity to meet. Restrictions of this kind are not only present in a university setting; they equally apply to many industrial scenarios, in which the search for sources of increased productivity and quality dominates over learning issues. Given these problems and given that more and more (German) universities consider transition-ing to a notebook university 1 , mobile pair programming based on specially equipped laptops appears to be a viable alternative. Local and motion independence increases the possibility of collaboration, the more so if campuses are widely distributed, students commute long distances or are otherwise separated; at the same time, ad-hoc networks allow collaboration over short distances (eg, for two collaborators travelling in a train). 2 Prior experience with stationary pair programming 2.1 Setup We have conducted a first small experiment among 60 students of a regular 200 h object-oriented programming project held during the 4 th semester of an applied informatics curriculum. Students were asked to divide up into ten equal-size groups, and each group was subsequently provided with four exercises, each comprised of six more or less independent tasks. Students were encouraged to process their tasks as pair programmers (two tasks for one pair) but could also solve them alone (one task per individual). After completion of each task, each student was asked to fill in a questionnaire asking for her/his experience, duration of task processing, and whether (s)he preferred pair programming over working alone. In order to avoid bias based on personal sym-pathy/antipathy, we required pairs to rotate within each group after each block. Although we never intended to declare our experiment a serious study, we had at least hoped to arrive at comparative results of some credibility. Unfortunately, outcome was basically incompa-rable, so that our experiment collapsed to a rather general pair programming acceptance test. However, we'd like to stress here that this was not an inherent flaw in our initial study design, but rather …